% This is LLNCS.DEM the demonstration file of
% the LaTeX macro package from Springer-Verlag
% for Lecture Notes in Computer Science,
% version 2.3 for LaTeX2e
%
\documentclass{llncs}
\usepackage{graphicx}
%
\usepackage{makeidx}  % allows for indexgeneration
%
\newcommand{\ff}[1]{ \begin{large}\textbf{#1}\end{large} }
\newcommand{\todo}[1]{ \begin{large}\textbf{#1}\end{large} }
%
%\graphicspath{{pics/}{img/}}

\begin{document}
%
\title{My Corporis Fabrica~: a Unified Ontological, Geometrical and Mechanical View of Human Anatomy}
%
\titlerunning{MyCorporisFabrica}  % abbreviated title (for running head)
%                                     also used for the TOC unless
%                                     \toctitle is used
%
\author{Olivier Palombi\inst{1,2} \and Guillaume Bousquet\inst{1} \and David Jospin\inst{1,2} \and Sahar Hassan\inst{1} \and Lionel Rev\'eret\inst{1} \and Fran\c{c}ois Faure\inst{1}}
%\author{Anonymous version.}
%
\authorrunning{Olivier Palombi et al.}   % abbreviated author list (for running head)
%\authorrunning{Anonymous}   % abbreviated author list (for running head)
%
%%%% list of authors for the TOC (use if author list has to be modified)
%\tocauthor{Ivar Ekeland, Roger Temam, Jeffrey Dean, David Grove,
%Craig Chambers, Kim B. Bruce, Elisa Bertino}
%
\institute{LJK Lab, Grenoble Universit\'es, CNRS, INRIA Rh\^one-Alpes, France \and Laboratory of Anatomy, Grenoble Universit\'es, France}
%\institute{Anonymous}

\maketitle              % typeset the title of the contribution

\begin{abstract}
A new anatomical database, My Corporis Fabrica (MyCF), is presented. It's based on the reference anatomical ontology FMA (the Foundational Model of Anatomy) with the possibility to coherently integrate 3D geometrical data, as well as biomechanical parameters. The purpose of this extension is to allow the user to intuitively create a patient-specific 3D representation from a formal description of anatomical entities and also to automatically export this description to test a physical simulation. The main contribution of MyCF consists in the formalization of a comprehensive database structure implemented in MySQL, linking canonical description of anatomical entities with reality-grounded instances of such description in terms of geometrical data and physical attributes. The principle of ontology modeling inherited from FMA is maintained in order to guarantee a close consistency between the two databases. A detailed illustration is given for the knee. In this example, the canonical description of anatomical entities is developed, including the location of attachment of ligaments as well as their stiffness, using an intuitive 3D GUI. Finally, an instance of the knee based on this description is automatically augmented with the canonical part information and then exported to a physical simulator. This example shows the benefit of coupling an exhaustive description of the anatomical structures with a physical simulation to study the dynamic effect of ligaments on the stability of the knee articulation.
\end{abstract}

\section{Introduction}
Anatomical models of human body are required in an increasing number of domains, from the teaching of anatomy to biomechanical simulation. Typically, accurate 3D representation of human anatomy is needed in application such as surgery simulator, realistic prototyping of cloth or representation of avatars in 3D virtual communities. The 3D representation of internal anatomy entities is primarily accessible from medical imaging such as CT or MRI tomography. These imaging techniques provide a raw volume and need to be segmented to identify individual anatomical entities. Even if some powerful methods have been proposed, this segmentation step is still time consuming as it cannot be fully automatic. An alternative approach to volumetric segmentation is to use 3D models designed by artists, but this involves a risk of loss in realism. Therefore, the need for a validated anatomical database of the human body linked with 3D representation is rapidly growing. This database should provide high-level information such as ontological relationships, as well as geometrical data for graphics applications and physical parameters for simulations. It should be extensible and anatomically relevant to integrate new conceptual entities, physical instances and characterization parameters. This is the goal of our approach with the design of the My Corporis Fabrica (MyCF) database. Specifically, MyCF extends FMA (the Foundational Model of Anatomy) \cite{Rosse1998} to provide additional data to create geometrical and mechanical models of anatomy. It is based on a novel database structure which considerably facilitates its extensibility. The remainder of this paper is organized as follows. In section \ref{sec:pw}, we review previous work in the domain. The design of MyCF database is presented in section \ref{sec:design}. Implementation details are discussed in section \ref{sec:implementation}. An overview of potential applications is presented in section \ref{sec:applications}. Concluding remarks are presented in section \ref{sec:conclusion}.

\section{Previous work} \label{sec:pw}

Integrating patient-specific content into computational resources requires the use of formal and logical representation of anatomical knowledge. The field of computing science focused on structuring knowledge is called \textit{ontology}. Ontologies of anatomical knowledge has been widely performed with a high level of details and complexity. The FMA can be presented as the most sophisticated anatomical ontology available today for the scientific community \cite{Rosse2003}.  FMA follows the OBO-Foundry principles \cite{Smith2007}, one such principle being that descriptions about distinct domains belong to distinct ontologies. FMA is a symbolic representation of the phenotypic structure of human body. Therefore, FMA do not contain topology , geometrical and functional data. Such information should be stored in other ontologies. The technical complexity involved in formalizing the anatomy can not handle general variability in any easy way. Specific approaches have to be imagined to address this issue. This lacking link is the key point in the emerging research field of \textit{semantic 3D media} \cite{focus3D} and more specifically for medical applications \cite{magnenat-thalmann09,3dha}.

The Digital Anatomist Information System is based on FMA to link graphical and symbolic representations of anatomy \cite{Brinkley1997a}. A static 3D content (pictures of 3D models) is available to illustrate the FMA's concepts. But 3D data are not completely integrated in the ontology. Starting from FMA to embed ontology into specific computational resources seems to be relevant regarding the level of compliance with modeling principles used in FMA \cite{Zhang2006a}.  FMA is available in several formats, independent of any specific authoring environment. FMA is implemented with an open source ontology editor and knowledge-base framework called \textit{Prot\'eg\'e}. Data are stored in a \textit{MySQL} table but direct access to query is not intuitive. A querying agent exists for FMA but the flexibility of use is restricted \cite{Mork2003}. 

Only structural anatomy has been considered in FMA (OBO-Foundry principles). Topology, geometry and functions are required to build an efficient ontology for physical simulation. Strategy to extend FMA for a specific purpose is presented in \cite{Rosse2005}. An original approach, strictly limited to the muscoloskeletal system, has been proposed by Charbonnier et al. \cite{Charbonnier2007}. In the semantic-driven clinical examination platform, presented by Charbonnier et al., FMA is not extended. Anatomical knowledge is retrieved from FMA and functional information are combined in a second step to generate physical simulation through a specific platform. However, the main idea is similar to what MyCF intends to address.


\section{Database design} \label{sec:design}
\subsection{Generic concepts}
An ontology is a specification of a conceptualisation \cite{Gruber1993}. Common components of ontologies include classes, attributes and relations. Classes are sets, abstract objects, entities, concepts. Classes have attributes or properties. Relations make links between classes. Each relation has a conceptual meaning. For instance in the following sentence:  ``The patella is a \textit{part of} the knee and \textit{is a} bone organ'', relations (\textit{is\_a} and \textit{part\_of}) used between anatomical entities (patella, knee and bone organ) give a formal and logical description of canonical anatomy. \textit{Is\_a} and \textit{part\_of} are also called hierarchical relationships. The key point to build an ontology for specific application is the use of associative relationships (domain-specific) which must be clearly defined \cite{Smith2005a}.

The general purpose of an ontology is to provide a mean of classifying individuals. Patient-specific data are \textit{instances} of canonical anatomical entities stored in the ontology. Three kinds of binary relations can be used to manage efficiently anatomical knowledge and individuals: $<class, class>$ seen below, $<instance, class>$ and $<instance, instance>$.

MyCF is focused on the managing of individuals through an intuitive graphic user interface for non-expert users in ontology. The goal is to allow anatomists to contribute to the canonical part of MyCF. By this way, anatomical content of MyCF will be validated by experts. On the other hand, an user of MyCF can add individual content and get correct anatomical information as terminologies, functions, localizations, interactions and so on.

MyCF is based on FMA for the ontological description of anatomy. An original MySQL schema is proposed to ease sharing and extension, as explained in the subsection~\ref{schema} and to manage individuals. A SQL query is enough to retrieve data from one or more tables, allowing efficient implementation in a specific application.

\subsection{Description of the mySQL database}\label{schema}

\begin{figure}
\begin{center}
\begin{tabular}{c}
 \includegraphics[height=0.5\linewidth]{mycf_sql_SCHEMA.eps}
\end{tabular}
\end{center}
\caption{Entity Relationship Diagram of MyCF's database. The canonical anatomy part is on the top and the individuals part is on the bottom. Black lines depict relationships (1:n) between tables. Two bold lines show the relationships between the canonical and the individual parts. The dotted line depicts a relationship used to force user to select an existing anatomical entity (restricted to anatomical segment) during insertion process of a new acquisition in the database.} \label{fig:sqlschema}
\end{figure} 

The figure \ref{fig:sqlschema} shows the logical structure of MyCF's database. The  entity relationship diagram (ERD) can be divided in two main parts: canonical anatomical knowledge on one hand  and individual data on the other hand. %using ontology modeling principles

\subsubsection{MyCF's canonical part:}\label{subsec:canonical_part}

All canonical classes of MyCF are stored in the main table called \textit{Anatomical Entities}. An ontology id, used as a primary key, is given for each one. Definition and favorite name are available as well.

In an ontology, anatomical entities are organized into a hierarchy named taxonomy. A taxonomy is a directed acyclic graph satisfying some conditions \cite{Zhang2006a}. Our database schema allows to represent generic graphs, including directed acyclic graphs. Each entry of \textit{Relation\_Type} defines a graph, which can be a taxonomy or a more general graph, where its nodes are contained in \textit{Anatomical Entities} and its oriented edges in \textit{Relation}.

In practical terms, the table called \textit{Relation\_Type} gives definition of relations. For instance, the relation \textit{is\_a} is defined here with text definition and examples. The binary relations between anatomical entities are stored in the table called \textit{Relations} where parents and son are defined using anatomical entity ids and where the type of relation is given.

The attributes are managed also with two tables. The table \textit{Attributes} defines the properties of \textit{Anatomical Entities}. The table \textit{Attributes\_Type} ensures the genericity of the attributes.

With those five tables, it is possible to expand endlessly MyCF without adding tables. Furthermore, the simple organization allows users to write his own SQL queries to retrieve or update data. 

\subsubsection{MyCF's individual part:}
Instances are linked to anatomical entities. The 1:n relationship (bold line in figure \ref{fig:sqlschema}) allows to have many instances of one anatomical entity. Instances have specific attributes, the position in a 3D scene for instance. The types of attributes are stored in the canonical part of the database. But the attribute's value of a given instance is saved in the table called \textit{Instance\_Attributes}. Furthermore, general information can be stored in the canonical part of the database as, for instance, the yellow color conventionally used to depict bones in anatomical drawings. If the color is not given by the user for an instance, color stored in the canonical part can be automatically retrieved. By this way, a priori anatomical knowledge can be used to complete patient-specific content. The origin of patient-specific 3D data is a set of medical images (after segmentation). 3D models coming from a given acquisition will be used together to generate a 3D scene. The table called \textit{Acquisitions} is used to manage it.


\subsection{Instances}

Geometry is one of the most challenging issues in anatomy modeling. Each anatomical entity can be represented using various types of geometric models (volumetric images, surface or volume meshes, analytical surfaces, implicit surfaces, etc.) at various resolutions or levels of detail. Consequently, we can not store one single geometrical description for each anatomical entity. So, we store, for each entity, a set of instances referenced by file names. We set no limitation on the file format and the type of geometric models. We have developed plugins for Blender \cite{blender}, a free and open-source geometric modeler, to edit geometrical models of MyCF, see Fig~\ref{fig:blender}. It handles surface meshes and can be used to modify shapes, to displace and resize objects and to label areas such as ligament attachment places. 

\begin{figure}
\begin{center}
\begin{tabular}{c}
 \includegraphics[height=0.5\linewidth]{blender.eps}
\end{tabular}
\end{center}
\caption{Blender is used to edit individual geometrical models. Blender objects are created from information stored in MyCF (import script). Positions, insertions of ligaments are editable and modifications can be saved in MyCF (exportation script). The tibial collateral ligament (MYCF:00031) is under edition. The ligament has two extremities (the proximal and the distal extremity) which are defined in MyCF.\label{fig:blender}}
\end{figure} 

Geometry is often modeled based on medical images which represent several anatomical entities, which can be consistently viewed or simulated together.
We therefore gather the anatomical entities modeled from a given set of medical images in \textit{acquisitions}, which allows us to retrieve all of them simultaneously from the database.


\section{Implementation} \label{sec:implementation}

To ensure flexibility and extension, the canonical part of the database is described by only five tables. The ontology contains many taxonomies, as defined in section~\ref{subsec:canonical_part}. As a consequence, many graphs are spread into this five tables and information retrieval can be tedious. To easily exploit the \textit{MyCF} database, we propose a library called \textit{libmyCF}, written in python. It contains classes representing the anatomical entities, their relations and attributes and some useful algorithms are present.

In the canonical part, we automatically deal with the case of the attributes inheritance. So, when the attributes of an anatomical entity are required, all the attributes of this entity are returned, plus all the attributes of its parents, defined by the relation \textit{is\_a}, if the parsed attributes are not yet defined.

If the value of an attribute is modified and this attribute is inherited, a new attribute is created for this anatomical entity. Instance attributes are shown in the figure \ref{fig:MyCF}.

\begin{figure}
\begin{center}
\begin{tabular}{cc}
 \includegraphics[height=0.45\linewidth]{myCF_main.eps} &
 \includegraphics[height=0.4\linewidth]{myCF_edit.eps} \\
(a) & (b)
\end{tabular}
\end{center}
\label{application}
\caption{\label{fig:MyCF}MyCF graphical user interface. \textbf{a)} Main window of MyCF. 1.the anatomical entities tree for the relation \textit{part\_of}, 2.information about the anatomical entity (AE), 3.attributes for this AE, 4.VTK visualization of an instance example. \textbf{b)} Edition of an anatomical entity. All the attributes and the relations of this anatomical entity are listed and editable here.}
\end{figure} 

In the individual part, when the required instance does not exist, a new instance is created using the corresponding anatomical entity information. On the same way, when the required instance attribute is missing, it is automatically created from the attribute of the same type of the anatomical entity corresponding to the instance.

For instance, let us consider a knee modeled by two bones (femur and tibia) and a ligament, see Fig~\ref{fig:blender}. During the importation of the instances into Blender, we need to know where to insert the extremities of the ligament on the bones. To do that, we just have to request the attribute named \textit{position}. Usually, the value of this instance attribute is retrieved and the extremity is placed. Then, we can modify the position of the extremity on the bone in Blender and export this new value into the database.

The first time the extremity is imported into Blender, the instance attribute is not set in the database. When the import script treat the instance 'extremity of the ligament', the position value is requested. As there is no instance attribute, a new one is automatically created from the attribute of the anatomical entity corresponding to the instance of the extremity. Then, modifications can be done in Blender and exported.

Thus, the link with the knowledge contained in the canonical anatomical model is automically managed by the library, and plugins using MyCF information are easy to write.



\section{Applications} \label{sec:applications}
Gathering ontological, geometrical and mechanical data consistently in a database allows new applications. We sketch some of them in this section.
\subsection{Teaching}
An obvious application of the database is the teaching of anatomy. MyCF can be used by students to handle anatomical knowledge within a consistent presentation. The graphical representations of anatomical entities allow a more intuitive way for knowledge-based navigation and understanding, as illustrated in Fig~\ref{fig:MyCF}. Each anatomical entity can be displayed in 3D, while its logical relations with the other entities appear in the interface.  Variability can be seen as well through 3D instances saved in the database.  The Digital Anatomist Interactive Atlases integrates the FMA with 3D graphical illustrations but without real 3D interaction \cite{A-WonRosBri99}. 

\subsection{Mechanical models}
Beside geometry, we store mechanical parameters in the database, which allows to export an acquisition to physical simulation engines.
The user can select the anatomical entities to export and the mechanical models to physically simulate them. 
For instance, to simulate a knee, the user can decide to export the bones and the main ligaments.
Various mechanical models can be used to represent a given object, depending on the purpose of the simulation. 
For instance, studying the kinematics of a given joint based on bones and ligaments requires rigid bone models.
Alternatively, studying bone fractures requires deformable models such as finite elements.
When the rigid model is applied to a given entity, its mass and inertia matrix are automatically computed based on geometry and density.
Alternatively, the user can chose to model an entity as a Finite Element Mesh with Hooke material. 
In this case, the same process is used to compute the mass and stiffness matrices, depending on the geometry, the shape functions as well as material parameters.

Deformable models such as finite elements require volumetric meshes.
Meshes are an important issue in simulation, and we can not propose all meshing algorithms using various complexity and quality parameters. 
When volumetric tetrahedral meshes are available in the geometric data, they can be easily exported to finite element simulation modules.
The precision and the computation time of finite element simulations heavily depend on the geometrical quality and the resolution of the volumetric meshes.
Nesme et al.'s grid-based finite elements use deformable regular grids embedding objects defined by arbitrary geometrical models~\cite{A-NesKryJerFau09}. 
The grids have arbitrary resolution, which allows to trade off accuracy for speed according to the application, and the geometrical quality is not an issue since all cells are cubes.
This approach allows to create finite element models for any virtual object at desired resolution.

\subsection{Completion of a model}
A priori knowledge is useful to complete models where all anatomical entities are not defined.
For instance, bone models may be built based on a CT-scan acquisition, whereas the connective tissues are not easily visible on the same data. In such a context, performing the mechanical simulation of a knee requires adding ligaments to the model, based on the knowledge of the ligaments properties and insertions locations on the bones.

MyCorporisFabrica allows the automatic creation of missing anatomical entities, using geometrical and material knowledge. The current implementation allows the creation of the main ligaments of the knee. The skeletal ligaments are modeled as one-dimensional mass-spring networks attached to the bones. To manage attach points, we have subdivided each ligament (using the \textit{part\_of} relation) in a proximal and a distal extremities. The areas on bones where skeletal ligaments are attached are clearly defined in the ontology. We use the relation \textit{is\_inserted\_on} to inform where ligament's extremities are inserted. That exact position required for a given instance should be added manually. We're currenlty working on an automatic process to localise ligament insertions on instances using anatomical knowledge. 
Default values for spring stiffness and damping constants are stored in the database, as well as a default number of particles for the ligament. These values are modifiable by the user at creation time. Moreover, the 3D editor can be used to modify the attach points.
Figure~\ref{fig:kneemodel} illustrates this process.

\begin{figure}
\begin{center}
\begin{tabular}{cc}
 \includegraphics[height=0.2\linewidth]{genou1.eps} & 
 \includegraphics[height=0.2\linewidth]{genou7.eps} \\
(a) & (b)
\end{tabular}
\end{center}
\caption{Completion of a model. \textbf{a)} Knee bones from an acquisition. \textbf{b)} Ligament models not visible in the acquision are added using anatomical knowledge.} \label{fig:kneemodel}
\end{figure} 

Once the model is complete, it can be exported to a simulation engine, as illustrated in Figure~\ref{fig:kneesimulation}. We use the SOFA simulation library~\cite{sofa} because it handles a variety of mechanical models and their interactions, it is free, open-source and highly customizable. 
However, export plugins to other simulation engines could be easily added to My Corporis Fabrica.

\begin{figure}
\begin{center}
 \includegraphics[height=0.20\linewidth]{genou4.eps}~
 \includegraphics[height=0.20\linewidth]{genou5.eps}~
 \includegraphics[height=0.20\linewidth]{genou6.eps}
\end{center}
\caption{Snapshots of a SOFA simulation of the model shown in Figure~\ref{fig:kneemodel}, with four ligaments. } \label{fig:kneesimulation}
\end{figure} 

Currently, information encoded in digital shape is implicit. Coupling geometric information with knowledge can be a solution to get a computational access to embedded information. In the domain of patient-specific anatomy,  digital shapes understanding will take a central role. Completion of a model is one of the most interesting application of anatomical ontology. A complete automatic process of completion have to deal with shapes understanding. A system to perform non-trivial segmentations of 3D surface meshes and to annotate the detected parts through concepts expressed by an ontology is presented by Attene et al. \cite{Attene07}. A similar approach is presented to handle multimedia content available on the Web in \cite{DeFloriani07}. MyCF has to include  metadata to ease shapes understanding. 

\section{Discussion} \label{sec:conclusion}
The main idea, which drives MyCF project, is to make available to the scientific community an open collaborative anatomical platform focused on the managing of patient specific data. Interested scientists should install and use MyCF on is own system (a MySQL server is required). We expect feedback from users. In the same time, we plan to maintain a open reference database with available 3D models. Access to MyCf as open source should facilitate further extensions. The curators of MyCF will be in charge to maintain consistency in anatomical representation. Therefore, access to manage this part of MyCF will be under restricted control. 

To the best of our knowledge, MyCF is the first multidisciplinary project focused on a close collaboration around anatomical physical simulations. The anatomits can find a formal frame for anatomical knowledge with interactvie 3D visualization and nonanatomist users can manage patient-specific content through confirmed anatomical concepts. 

MyCF is a brand new project. The knee is presented as a case study and has been used to built the system. We plan to increase amount of anatomical enities in MyCF. To do so the collaboration between users and curators must be strong and active. A collaborative web site around MyCF has been recently opened for this purpose. Readers are invited to visit \textit{\url{www.mycorporisfabrica.org}}. In the future, MyCf should be included in the OBO Foundry (\textit{www.obofoundry.org}).


%
% ---- Bibliography ----
%
\bibliographystyle{splncs}
\bibliography{biblio}
% \bibliographystyle{splncs}
% \bibliography{biblio}
\end{document}

